Telemetry typically refers to wireless communications, such as a radio system, telephonic, computer network, optical link or by wire. Telemetry (often synonymous with telematics) is a technology that allows the remote measurement and reporting of information of interest to the system designer or operator. Systems that use instructions and data sent to them to operate use telecommand, the counterpart of telemetry. Telematics systems typically combine telecommunications and information processing, and frequently utilize remote devices.
M2M refers to data communications between machines. M2M is most commonly translated as Machine-to-Machine but has sometimes been translated as Man-to-Machine, Machine-to-Man, Machine-to-Mobile and Mobile-to-Machine. Like all evolving technologies, its definition continues to evolve, but it generally refers to telemetry or telematics that is accomplished using data networks including, but not limited to, public wireless data networks. M2M can also mean the family of sensors, middleware, software and applications that help improve efficiency and quality by tying together a myriad of sensors with mission critical applications like asset management, enterprise resource planning (ERP), and customer resource management (CRM).
In the past, telemetry systems were the exclusive domain of very large well-financed organizations. NASA used telemetry extensively from the very beginning of the space program, which was probably one of the first applications. Large oil and gas companies and electric utilities, through the use of extensive customer-built and dedicated data networks, were among the first private organizations to use telemetry.
In recent years, the cost of access to public wireless data networks (CDMA, GPRS, Mobitex, etc.) is decreasing while the capability of these networks continues to increase. M2M generally includes technology that leverages these networks to bring telemetry to a much wider audience. In addition, M2M sometimes refers to similar leveraging of the Internet leading to the pervasive Internet. The pervasive Internet refers to the deployment of web services on devices, smart metering, and new streaming sensor technologies that creates “data torrents and rivers” of such volumes that traditional data warehouses and analytic tools struggle to keep up and manage the information, let alone provide close to real-time analytics, processing, and controls based on that information.
As the scope of M2M has evolved, other terms like Machine to Human (M2H) and Machine to Enterprise (M2E) are starting to emerge to segment the pervasive nature of the M2M term. The M2M device, software, network, and service market is expected to grow rapidly worldwide in the near future. There are on the order of a half billion computers in the world and over one and a half billion cell phones and PDAs, and it is estimated that there are more than 38 billion other electronic devices that have information relevant to improving an enterprise operations. For instance, vehicle containers, tankers, supply chain assets, items with SKU's, medical devices, HVAC, industrial machinery, distributed generation, industrial controllers, appliance controllers, vending machines, vehicle locators, and the like are all candidates for telemetry applications. The M2M market strives to connect these devices to corporations, governments, institutions, and individuals.
Dealing with different devices and networks can be a burden to developers, since each device may have a different communication protocol, and different networks have different interface requirements. Initially, if a developer was versed in the inner workings of the device operating system, a custom device driver was written for controlling the device operation, but this was time consuming and required intimate knowledge of device operation. The industry moved from custom designs to an application programming interface (API). An API is a set of routines, data structures, object classes and/or protocols provided by libraries and/or operating system services to support the building of applications. An API may be language-dependent; that is, available only in a particular programming language, using the particular syntax and elements of the programming language to make the API convenient to use in its particular context. Alternatively, an API may be language-independent; that is, written in a way that means it can be called from several programming languages (typically an assembly/C-level interface). This allows a service-style API that is not bound to a particular process or system and is available as a remote procedure call.
The API itself is largely abstract in that it specifies an interface and controls the behavior of the objects specified in that interface. The software that provides the functionality described by an API is said to be an implementation of the API. An API is typically defined in terms of the programming language used to build an application. The related term, ABI (Application Binary Interface), is a tower level definition concerning details at the assembly language level. For instance, the POSIX standard defines an API that allows a wide range of common computing functions to be written such that they may operate on many different systems; however, making use of this requires re-compilation for each platform. A compatible ABI, on the other hand, allows compiled object code to function without any changes, on any system implementing that ABI. This is advantageous to both software providers (where they may distribute existing software on new systems without producing/distributing upgrades) and users (where they may install older software on their new systems without purchasing upgrades), although this generally requires various distributed software libraries implementing the necessary APIs. Library versioning, device addressing and message handling across varied networks encumber software designers and end users.
An advantageous process over API solutions is utilizing OLE for Process Control (OPC). The OPC specification was based on the OLE, COM, and DCOM technologies developed by Microsoft for the Microsoft Windows operating system family. This specification defined a standard set of objects, interfaces and methods for use in process control and manufacturing automation applications to facilitate interoperability. OPC was designed to bridge Windows-based applications and process control hardware and software applications. The standard defines a consistent method of accessing field data from distributed devices. This method remains the same regardless of the type and source of data. OPC servers provide a method for many different software packages to access data from a process control device, such as a PLC or DCS. Traditionally, any time a package needed access to data from a device, a custom interface, or driver, had to be written. The purpose of OPC is to define a common interface that is written once and then reused by any business, SCADA, HMI, or custom software packages. Once an OPC server is written for a particular device, it can be reused by any application that is able to act as an OPC client. OPC servers use Microsoft's OLE technology (also known as the Component Object Model, or COM) to communicate with clients. COM technology permits a standard for real-time information exchange between software applications and process hardware. However, lack of security, lack of scalability, frequent configuration issues with DCOM, lack of configurable timeouts, and its restriction to the Windows Operating System were significant drawbacks to OLE for process control.